Noncontact ic card communication system and communication method

ABSTRACT

Communication processing is performed so as to correspond to multiple types of contactless IC cards having different specifications, such as command classes and security algorithms. Without performing a process for a command or response result communicated with an IC card, a reading device encapsulates the command or result into a command that is called a through command and that is independent of the type of IC card and delegates the process to a controller module. Thus, the reading device is independent of the type of IC card. A command and a process procedure which depend on the type of IC card are taken care of by a replaceable software module that is provided in the controller module and that corresponds to the card.

TECHNICAL FIELD

The present invention relates to contactless communication systems forperforming transmission between a primary coil and a secondary coil byutilizing an electromagnetic induction effect. In particular, thepresent invention relates to a contactless-IC-card communication systemand a communication method in which an IC card having a secondary coiltransmits a response signal as a result of load variation in response toan electromagnetic-based query signal transmitted from a card readingdevice having a primary coil.

More specifically, the present invention relates to acontactless-IC-card communication system and a communication method inwhich a card reading device performs communication processing with acontactless IC card by using a predetermined command class and asecurity algorithm through a predetermined card-detection procedure. Inparticular, the present invention relates to a contactless-IC-cardcommunication system and a communication method for performingcommunication processing for multiple types of contactless IC cardshaving different specifications, such as command classes and securityalgorithms.

BACKGROUND ART

One example of wireless communication means that are locally applicableis a contactless IC card.

This type of wireless communication is commonly achieved based on anelectromagnetic induction principle. That is, the configurationincludes, at least, an IC card having a memory function and a cardreader/writer that performs read/write access on the memory of the ICcard. An IC-card-side loop coil, which serves as a primary coil, and acard-reader/write-side antenna, which serves as a secondary coil, formone transformer as a unit. The card reader/writer transmits power andinformation to the IC card by similarly using an electromagneticinduction effect and the IC card is actuated by the supplied power tothereby be able to respond to a query signal from the cardreader/writer.

The card reader/writer modulates current to be supplied to the antennato thereby cause a loop-coil induced voltage on the IC card to bemodulated. Due to the effect, the card reader/writer can transmit datato the IC card. Also, a variation in load between loop-coil terminals ofthe IC card causes an impedance between antenna terminals of the IC cardreader/writer to change, so that a voltage and current passing throughthe antenna fluctuate. Due to the effect, the IC card returns a responseto the card reader/writer.

A contactless proximity communication system, typified by an IC card, isbeginning to become widespread because of simplicity in operation. Forexample, with an IC card on which personal identification code, otherpersonal authentication information, and value information of anelectronic ticket or the like are stored, a card reader/writer installedat a cash dispenser, an entrance of a concert venue, or a ticket gate ofa station can perform authentication processing by performingcontactless access to the IC card held by the user.

FIG. 9 schematically depicts the configuration of a ticket-gate system 1that is implemented using contactless communication. A user carries acontactless IC card 2 even when he or she is in transit. A ticket gatemachine 4 is installed at a ticket gate of a station, and uses anopening/closing operation of a passage gate 8 to control whether or notto permit the passage of the user in accordance with whether or not abilling process is finished or whether or not other authorization isgiven. A card reading/writing device 6 is installed on the ticket gatemachine 4 for use. When the user attempts to pass through the ticketgate, the card reading/writing device 6 accesses the IC card 2 in thepossession of the user to read/write data.

The card reading/writing device 6 constantly transmits a polling commandto IC cards. When the user approaches the ticket gate machine 4 whilecarrying the IC card 2, the card reading/writing device 6 installed onthe ticket gate machine 4 detects the approaching of the IC card 2(i.e., detects the card) and performs communication (collision avoidanceand card determination) with the IC card 2. When the passage ispermitted after the billing process and mutual authentication processare performed on the user, the passage gate 8 is opened to permit theuser to pass through the ticket gate.

Recently, IC cards having memory spaces with relatively large capacitieshave emerged in conjunction with improvements in micro-fabricationtechnology. Since an IC card having a large-capacity memory can storemultiple applications (or services) at the same time, one IC card can beused for multiple applications. For example, when many services, such aselectronic money for electronic payment, an electronic ticket for entryinto a specific concert venue, are stored on one IC card, the IC cardcan be applied to various applications.

Further, when an individual device is equipped with both functions ofthe IC card and the card reader/writer, the IC card technology can beutilized for a versatile bidirectional proximity communicationinterface. For example, when a proximity communication system isconstituted by such apparatuses as a computer and a home-electronicinformation apparatus, the communication is performed on a one-to-onebasis. Also, one apparatus can communicate with a non-apparatuscounterpart device (which will be referred to as a “card”), such as acontactless IC card. In such a case, an application for performingone-to-many communication between one apparatus and multiple cards isalso possible.

While IC cards are rapidly coming to widespread use, there is also aproblem in that multiple interface standards coexist. For example,although international standardization for proximity contactless ICcards have been promoted based on ISO/IEC 14443, there are still twotypes of specifications: type A and type B. Accordingly, in order todetect which type of card enters the operation space, the readerperiodically and alternately transmits respective request commands(e.g., refer to “RFID Handbook—Principle and Application of ContactlessIC Card” by Ryoji Iga et al., pp 175-187 (Kabushikigaisha SoftwareKogaku Kenkyusho). Other than those standards, card venders thatmanufacture and sell IC cards and card reading devices provide variousinterface standards for their IC cards. Further, the current situationis that command classes are different from each other, even wheninterface standards are the same.

The biggest problem in the contactless IC card technology is thatdifferent standards preclude compatibility and thus compatibility cannotbe achieved in many cases even if standards are the same. The reason isthat, while specifications up to a certain portion are specified foreach standard, other specifications are independently formulated, thusmaking it impossible to achieve compatibility in the following points.

(1) Difference in Upper Layer Protocol

(2) Difference in Command Class

(3) Difference in Command Execution Procedure

(4) Difference in Security Algorithm

(5) Difference in Data Structure in Memory Space on Card

Examples of the security algorithms include a mutual authenticationscheme, an encryption scheme during data communication, checksum and MAC(message authentication code) generation methods. However, since thosealgorithms have security problems, the card venders do not make thespecifications public.

With regard to minimum specifications including physical and electricalspecifications, ISO/IEC 14443 specifies procedures performed when a cardreading device detects an IC card, such as initialization, collisionavoidance, and card determination for each type, but does not havestringent rules with regard to procedures after card determination.Therefore, the current situation is that a card-reading command andother commands after card determination vary among card venders and thuscompatibility is not maintained even the commands are within the sameinterface standard.

In order to overcome such a difference between standards of the cardvenders, for example, an approach in which a process (firmware)corresponding to a card type is burned on an IC chip of a single cardreading device is employed. For example, in an example shown in FIG. 10,a process firmware corresponding to a card specification supplied bycompany A and a process firm ware corresponding to a card specificationsupplied by company B are burned on an IC-chip ROM (read only memory) ina card reading device, so that a corresponding firmware is selectivelyexecuted in accordance with a card detected via an antenna so as toachieve compatibility with the respective cards of the venders.

According to the example shown in FIG. 10, a single card reading devicecan perform processing for contactless IC cards of different cardvenders. However, in order to achieve compatibility with a new type ofcard, work for re-burning a firmware in the IC chip arises. Thisrequires development cost and maintenance cost for the replacement work.Also, this approach cannot be used for all cases, since some cardvenders do not disclose their security algorithms related to cardprocessing.

Other methods for overcoming such a difference between standards of thecard venders involve a method in which a card-dependent process isstored in chip-module hardware, instead of burning a process on the ICchip, and the hardware is inserted in a slot of the card reading device.For example, in an example shown in FIG. 11, a card reading device isprovided with a plurality of chip module slots for replaceably insertingchip modules for card processing. Thus, when a chip module for a processcorresponding to a card specification supplied by company A and a chipmodule for a process corresponding to a card specification supplied bycompany B are inserted into the respective slots, a correspondingprocess firmware is selectively executed in accordance with a carddetected via an antenna so as to achieve compatibility with therespective cards of the venders: company A and company B. Further, whenit is desired to achieve compatibility with cards of another vender, thechip module can be removed and replaced.

According to the example shown in FIG. 11, a single card reading devicecan perform processing for contactless IC cards of different cardvenders. However, since this scheme restricts the number of chip modulesthat can be inserted into a reading device, card types that can behandled by one reading device are limited. Also, when card processing ischanged or a card type is changed, work such as developing a new chipmodule and disassembling the card reading device to physically replacechip modules arises.

Thus, all of the methods described above achieve processing in which onereading device can perform processes multiple types of cards, but do notmake it easier to achieve compatibility with cards other thanpredetermined card types.

Nowadays, requirements for constructing an open system that is notvulnerable to a difference for each vender are increasing, mainly, inAFC (automatic fare collection) systems of public transport facilities.This is because known AFC systems need to dependent on specific cardvenders and card-reading-device venders, thus making it difficult toconstruct a low-cost and highly-flexible AFC system. A further reason isthat various types of cards and reading devices appear on the market inconjunction with the widespread use of contactless IC cards in recentyears, thus making it realistic to construct a highly-versatile AFCsystem.

DISCLOSURE OF INVENTION

An object of the present invention is to provide a superior contactlessIC card communication system and a communication method in which a cardreading device can preferably perform communication processing withcontactless IC cards by using a predetermined command class and asecurity algorithm through a predetermined card-detection procedure.

A further object of the present invention is to provide a superiorcontactless IC card communication system and a communication methodwhich allow communication processing so as to correspond to multipletypes of contactless IC cards having different specifications, such ascommand classes and security algorithms.

The present invention has been made to overcome the foregoing problemsand provides a contactless-IC-card communication system that iscompatible with multiple contactless-IC-card specifications includingcommand classes different from each other.

The contactless-IC-card communication system includes a controllermodule unit for processing card-dependent commands that differ dependingon the contactless-IC-card specifications; and

a through reader unit for encapsulating a card-dependent commandreceived from a contactless IC card into a through command anddelegating a process to the controller module unit, and for retrieving acard-dependent command from a through command received from thecontroller module and transmitting a resulting command to thecontactless IC card.

The “system” used herein refers to a combination in which multipledevices (or function modules for accomplishing specific functions)gather logically and does not particularly restrict whether or not thedevices and function modules are provided in a single housing. Also, the“contact-IC-card specifications” used herein include, at least,initialization and collision-protection procedures, application-levelcommands, and application-level protocols, and security requirementswhich are defined on “interface standards (or, interfacespecifications)” that define electrical properties and data-link-levelprotocols.

According to the contactless-IC-card communication system of the presentinvention, the through reader unit can execute a card determinationprocedure that is common to contactless-IC-card interface standardsincluding card detection, collision avoidance, and card determination.

Thus, without performing a process for a command or response resultcommunicated between an IC card and the card reading device, the throughreader unit, which serves as a card reading device, encapsulates thecommand or result into a command that is called a through command andthat is independent of the type of IC card and delegates the process toa controller module. This makes it possible to provide a card readingdevice that is independent of the type of IC card.

The controller module unit selectively executes multiple softwaremodules containing command classes corresponding to the respectivecontactless-IC-card specifications, processes a card-dependent commandfrom the contactless IC card, and generates a card-dependent command forthe contactless IC card. The software modules are modularized for therespective contactless-IC-card specifications, in units of programs inwhich command groups and security algorithms corresponding to therespective contactless-IC-card specifications as well ascommunication-process procedures are written.

Further, the controller module further includes a common-processexecuting software module for executing a process that is independent ofa difference between the contactless-IC-card specifications.

The software modules are downloaded to the controller module unit froman external server or the like, for example, during the installation ormaintenance of the system.

According to the contactless-IC-card communication system of the presentinvention, a command and a process procedure which depended on the typeof IC card are taken care of by a replaceable software module that isprovided in the controller module and that corresponds to the card.Merely replacing the software module can make it easier to achievecompatibility with a new type of IC card and to make a change to processcontent for a currently-available IC card.

Preferably, the controller module unit provides an application firewallfunction for preventing the software modules from interfering with eachother and a secure execution environment for preventing the softwaremodules from improperly accessing resources of the controller module.

The controller module unit can be configured so that it is shared bymultiple card reading devices and is delegated by respective throughreader units so as to perform a process for the card-dependent command.

In this case, upon obtaining a response signal from a card present inthe contactless communication area, each through reader unitencapsulates the received card-dependent command into a through commandand delegates the process to the integrated controller module unit. Inthe controller module unit, the software module corresponding to thecaptured card is started to generate a card-dependent command,encapsulate the generated command into a through command, and return theresulting command to the through reader unit that requested theprocessing. The through reader unit then retrieves the card-dependentcommand from the through command and transmits the resulting command tothe card without change.

With this configuration, the controller module functions can becentrally managed and work for downloading necessary software modulescan be completed by a single operation. This makes it possible toachieve cost reduction and maintenance simplification and to achievesystem expansion with relative ease.

The present invention can eliminate a need for constructing a systembased on the card of a specific vender and the reading device of aspecific vender. Thus, transportation operators and so on who constructcontactless-IC-card systems can easily procure system components and candesign flexible systems that are independent of venders.

According to the present invention, in situations in which card-processcontent is changed or a new type of card is employed, compatibility withnew card specifications can be achieved by externally replacing softwarewithout physically removing or disassembling a reading device, therebymaking it possible to reduce maintenance cost.

According to the present invention, since information that is notdisclosed by card venders, such as processes and security algorithmswhich are specific to card types, is concealed in the software modules,confidential information for each card vender is protected.

Further objects, features, and advantages of the present invention willbecome apparent from more detailed description based on an embodimentdescribed below according to the present invention and the accompanyingdrawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a diagram schematically showing the configuration of acontactless-IC-card-type card reading system 10 according to oneembodiment of the present invention.

FIG. 2 is a diagram illustrating the operation of the card readingsystem 10 when a response from a card is read.

FIG. 3 is a diagram illustrating the operation of the card readingsystem 10 when a command is issued to the card.

FIG. 4 is a diagram showing an example of an operation sequence for thecard reading system 10 to perform data communication with contactless ICcards.

FIG. 5 is a diagram showing an example in which the contactless-IC-cardreading system of the present invention is applied to an automatic farecollection device (fare collection device) for a train or the like.

FIG. 6 is a diagram showing an example of the configuration of anautomatic fare collection system.

FIG. 7 is a diagram showing another example of the configuration of theautomatic fare collection system.

FIG. 8 is a diagram showing the functional configuration of a controllermodule 12.

FIG. 9 is a diagram schematically showing the configuration of aticket-gate system that is implemented using contactless communication.

FIG. 10 is a diagram illustrating a known method in which processescorresponding to card types are burned on an IC chip of a single cardreading device to allow the single card reading device to performprocessing for contactless IC cards of different card venders.

FIG. 11 is a diagram illustrating a known method in which card-dependentprocesses are stored in chip-module hardware and the chip modules areinserted into slots of a card reading device to allow the single cardreading device to perform processing for contactless IC cards ofdifferent card venders.

BEST MODE FOR CARRYING OUT THE INVENTION

An embodiment of the present invention will be described below in detailwith reference to the drawings.

The present invention relates to a scheme in which a single readingsystem processes multiple contactless IC cards having differentstandards, such as command classes, for respective venders.

FIG. 1 schematically shows the configuration of acontactless-IC-card-type card reading system 10 according to oneembodiment of the present invention. The card reading system 10 shown inthe figure includes, mainly, a single or multiple software modules 11A,11B, . . . prepared for respective card types, a controller module 12for executing the software modules 11, a through reader 13 forcommunicating with contactless IC cards 20A, 20B, . . . at aphysical/electrical low-layer protocol level.

The software modules 11 are provided (modularized) for respective typesof cards, in units of programs in which command groups and securityalgorithms corresponding to respective contactless-IC-cardspecifications as well as communication-process procedures are written.A software module that is called a common-process executing softwaremodule 14 and that performs a process independent of a card type is alsoprovided.

In the present embodiment, the common-process executing software module14 determines the type of detected card, performs processing for sortinga process to the software module 11 for the corresponding card, andperforms a through-command process (described below). The process thatis independent of a card type, as used herein, includes, for example,calling an AES (Advanced Encryption Standard) or DES (Date EncryptionStandard) engine for performing encryption processing according to anencryption parameter received from the software module 11.

The software modules 11 for the respective cards of companies and thecommon-process executing software module 14 are downloaded from anexternal server 30 to the controller module 12 during the installationor maintenance of the system. In order to prevent the software modulesfrom being analyzed or tampered with through tapping by a third party,the software modules 11 are downloaded using a secure scheme with ananti-tamper IC chip 15 and are stored in the IC chip 15.

The controller module 12 executes the common-process executing softwaremodule 14 and the software modules 11 corresponding to respective cardspecifications of companies, the modules being stored in the IC chip. Inthe present embodiment, the controller module 12 provides an applicationfirewall function for preventing the software modules 11 frominterfering with each other and a secure execution environment forpreventing the software modules 11 from improperly accessing resourcesof the controller module 12.

The through reader 13 communicates with the contactless IC cards 20A,20B, . . . at a physical/electrical low-layer protocol level for cardinitialization, collision avoidance, card determination, and so onduring card detection. That is, the through reader 13 communicates witheach card, and without performing a process corresponding to a responseresult from the card, delegates the process to the controller module 12.

FIG. 2 shows the operation of the card reading system 10 when a responsefrom a card is read. Upon receiving a response from a card, athrough-command processor 16 in the through reader 13 transmits aresponse result, encapsulated in a command that is referred to as a“through command” and that is independent of a card type, to thecontroller module 12. The through-command process is implemented on ananti-tamper IC chip 17 to protect unauthorized uses, such as tapping andtampering of a card-dependent command.

In the controller module 12, the corresponding software module isexecuted to process a card-dependent command contained in a throughcommand. Specifically, the common-process executing software module 14determines a card type and sorts a process to the software module 11 forthe corresponding card. Then, the corresponding software module 11 isstarted, so that a command process procedure and a communication processprocedure corresponding to the card type are executed.

FIG. 3 shows the operation of the card reading system 10 when a commandis issued to a card. The software modules 11 have a group of commandscorresponding to card types and can generate card-dependent commands.When transmitting a command to a card, the controller module 12encapsulates a card-dependent command into a through command andtransmits the resulting command to the through reader 13. Thethrough-command processor 16 in the through reader 13 retrieves thecard-dependent command from the through command and transmits theresulting command without change. The through-command process isimplemented on the anti-tamper IC chip 17 to protect unauthorized uses,such as tapping and tampering of the card-dependent command (asdescribed above).

FIG. 4 shows an example of an operation sequence for the card readingsystem 10 of the present embodiment to perform data communication with acontactless IC card.

The common-process executing software module 14 issues a card-captureinstruction to the through reader 13. In response to the instruction,the through reader 13 alternately generates card-capture signals thatdiffer depending on card standards.

Upon receiving a response signal from card A that is present in thecontactless communication area of the through reader 13, thethrough-command processor 16 in the through reader 13 encapsulates thereceived response command into a through command and transmits theresulting command to the common-process executing software 14.

The common-process executing software module 14 determines a card type,sorts a process to the software module 11A for corresponding card A, anddelegates a command process.

The software module 11A for card A has a command process correspondingto card A, a security algorithm, and a communication process procedure.When the software module 11A generates a card-dependent command, thecommon-process executing software module 14 encapsulates the commandinto a through command and transmits the resulting command to thethrough reader 13. The through-command processor 16 in the throughreader 13 retrieves the card-dependent command from the through commandand transmits the resulting command without change.

Also, upon receiving a response signal form card B that is present inthe contactless communication area of the through reader 13, thethrough-command processor 16 in the through reader 13 encapsulates thereceived response command into a through command and transmits theresulting command to the common-process executing software module 14.

The common-process executing software module 14 determines a card type,sorts a process to the software module 11B for corresponding card B, anddelegates a command process.

The software module 11B for card B has a command process correspondingto card B, a security algorithm, and a communication process procedure.When the software module 11B generates a card-dependent command, thecommon-process executing software module 14 encapsulates the commandinto a through command and transmits the resulting command to thethrough reader 13. The through-command processor 16 in the throughreader 13 retrieves the card-dependent command from the through commandand transmits the resulting command without change.

FIG. 5 shows an example in which the contactless-IC-card reading systemof the present invention is applied to an automatic fare collectiondevice (fare collection device).

In the example shown in the figure, the automatic fare collection deviceincludes a through reader 13 and a controller module 12 and can readcards corresponding to interface specifications that differ depending oncard venders: company A, company B, and company C.

The controller module 12 provides an application firewall function forpreventing the software modules 11 from interfering with each other anda secure execution environment for preventing the software modules 11from improperly accessing resources of the controller module 12.

In order to be compatible with contactless IC card specifications ofcompany A, company B, and company C, the automatic fare collectiondevice pre-downloads the software modules 11A, 11B, and 11C, whichprocess the cards of the respective companies, from the external server30. In order to prevent the software modules from being analyzed ortampered with through tapping by a third person during the downloadprocess, the software modules 11 are downloaded using a secure schemewith an anti-tamper IC chip 15 and are stored in the IC chip 15.

The through reader 13 communicates with the contactless IC cards 20A,20B, . . . at a physical/electrical low-layer protocol level for cardinitialization, collision avoidance, card determination, and so onduring card detection. That is, the through reader 13 communicates witheach card, and without performing a process corresponding to a responseresult from the card, delegates the process to the controller module 12.

In response to a card-capture instruction from the controller module 12,the through reader 13 alternately generates card-capture signals thatdiffer depending on the card standards of the companies.

When a response signal is obtained from a card that is present in thecontactless communication area of the through reader 13, thethrough-command processor 16 in the through reader 13 encapsulates acard-dependent response command (proprietary command) into a throughcommand (through-command) and transmits the resulting command to thecontroller module 12 without change to thereby delegate a commandprocess.

In the controller module 12, the software module corresponding to thecaptured card is started to generate a card-dependent command,encapsulate the generated command into a through command, and pass theresulting command to the through reader 13. The through-commandprocessor 16 in the through reader 13 retrieves the card-dependentcommand from the through command and transmits the resulting command tothe contactless IC card without change.

In the through reader 13, the process for encapsulating thecard-dependent command into the through command and the process forretrieving the card-dependent command from the through command andtransmitting the resulting command are executed by a through command API(application programming interface). The through command API itself doesnot process the card-dependent command and thus can be used for all cardinterface specifications.

FIGS. 6 and 7 show examples of the configuration of an automatic farecollection system installed, for example, in station premises. Multipleautomatic fare collection devices are installed at, for example,respective ticket gates in station premises.

In the example shown in FIG. 6, respective automatic fare collectiondevices are equipped with independent controller modules 13 andnecessary software modules are downloaded to the respective controllermodule 13.

On the other hand, in the example shown in FIG. 7, multiple farecollection devices share one through reader 13. Each fare collectiondevice includes only the through reader 13. Upon obtaining a responsesignal from a card present in the contactless communication area, eachthrough reader 13 encapsulates the received card-dependent command intoa through command and delegates the process to the integrated controllermodule 12. In the controller module 12, the software modulecorresponding to the captured card is started to generate acard-dependent command, encapsulate the generated command into a throughcommand, and return the resulting command to the through reader 13 thatrequested the processing. The through reader 13 then retrieves thecard-dependent command from the through command and transmits theresulting command to the contactless IC card without change.

In the example shown in FIG. 7, the controller module functions can becentrally managed and work for downloading necessary software modulescan be completed by a single operation. This makes it possible toachieve cost reduction and maintenance simplification and to achievesystem expansion with relative ease.

FIG. 8 shows the functional configuration of the controller module 12.

The controller module 12 is implemented with a platform having acombination of an operating system (OS), a Java virtual machine (JavaVM), and a Java API. The platform is not limited to such a configurationto achieve the present invention, but it is preferable that the platformbe open and be based on a typical execution environment to allow variouscard vendors to freely develop an application.

The Java VM is a virtual computer that interprets and executes a programwritten in Java language, and executes a Java program that is convertedinto byte code by a Java compiler. The Java API is grouped (packaged) asa library of relevant classes and interfaces. The Java API and Java VMisolate a program and hardware.

The controller module 12 stores the software modules 11 for cardssupplied by card venders. Each software module 11 is a moduleincorporating all communication process procedures, such as a commandclass and a security algorithm corresponding to the specification ofeach card vender and is written in Java applet.

Java applet is a small application written in Java language and can bedistributed using a WWW (World Wide Web) technology. That is, Javaapplets are compiled in advance, are registered with a WWW server, andare specified with a tag “<applet>” in an HTML (hyper text markuplanguage) document.

The controller module 12 downloads a necessary card-processing softwaremodule from the external server 30. In the process of downloading thesoftware module, confidentiality needs to be ensured.

The platform of the controller module 12 provides an applicationfirewall function for preventing the software modules 11 frominterfering with each other and a secure execution environment forpreventing the software modules 11 from improperly accessing resourcesof the controller module 12. The Java platform prepares an off-the-shelf(i.e., ready-made) security mechanism.

In order to prevent the software modules 11 from being analyzed andtampered with through tapping by a third party, the software modules 11are implemented on an anti-tamper IC chip.

The controller module 12 is provided with an encryption coprocessor forDES (data encryption standard), AES (advance encryption standard), andso on and thus can achieve higher-speed encryption/decryptionprocessing.

The controller module 12 is also provided with an extension memory forcaching (temporarily storing) a software component and so on.

Buses that interconnect the encryption coprocessor, the extensionmemory, and the controller module 12 have a scrambling mechanism forpreventing tapping.

Supplement

The present invention has been described above in detail with referenceto the particular embodiment. However, it is obvious that those skilledin the art can make a modification and substitution to the embodiment ina scope without departing from the substance of the present invention.That is, the present invention has been disclosed by way of example andwhat is described herein should not be construed as limiting. Thesubstance of the invention is to be determined by taking the claims intoaccount.

INDUSTRIAL APPLICABILITY

The present invention can provide a superior contactless-IC-cardcommunication system and a communication method in which a card readingdevice can preferably perform communication processing with acontactless IC card by using a predetermined command class and asecurity algorithm through a predetermined card-detection procedure.

The present invention can further provide a superior contactless-IC-cardcommunication system and a communication method which allowcommunication processing so as to correspond to multiple types ofcontactless IC cards having different specifications, such as commandclasses and security algorithms.

The present invention can eliminate a need for constructing a systembased on a reading device of a specific vender and a card of a specificvender that provides more than one type of contactless IC cardsatisfying a specific contactless-IC-card specification. Thus,transportation operators and so on who construct contactless-IC-cardsystems can easily procure system components and can design flexiblesystems that are independent of contactless-IC-card specifications.

According to the present invention, in situations in which card-processcontent is changed or a new type of card is employed, compatibility witha new card interface specification can be achieved by externallyreplacing software without physically removing or disassembling areading device, thereby making it possible to reduce maintenance cost.

According to the present invention, since information that is notdisclosed by card venders, such as processes and security algorithmswhich are specific to card types, is concealed in the software modules,confidential information for each card vender is protected.

1. A contactless-IC-card communication system that is compatible withmultiple contactless-IC-card specifications including command classesdifferent from each other, the communication system comprising: acontroller module unit for processing card-dependent commands thatdiffer depending on the contactless-IC-card specifications; and athrough reader unit for encapsulating a card-dependent command receivedfrom a contactless IC card into a through command and delegating aprocess to the controller module unit, and for retrieving acard-dependent command from a through command received from thecontroller module and transmitting a resulting command to thecontactless IC card.
 2. The contactless-IC-card communication systemaccording to claim 1, wherein the through reader unit executes a carddetermination procedure that is common to contactless-IC-card interfacestandards including card detection, collision avoidance, and carddetermination.
 3. The contactless-IC-card communication system accordingto claim 1, wherein the controller module unit selectively executesmultiple software modules containing command classes corresponding tothe respective contactless-IC-card specifications, processes acard-dependent command from the contactless IC card, and generates acard-dependent command for the contactless IC card.
 4. Thecontactless-IC-card communication system according to claim 3, whereinthe controller module further comprises a common-process executingsoftware module for executing a process that is independent of adifference between the command classes of the contactless-IC-cardspecifications.
 5. The contactless-IC-card communication systemaccording to claim 3, wherein the software modules are modularized forthe respective contactless-IC-card specifications, in units of programsin which command groups and security algorithms corresponding to therespective contactless-IC-card specifications as well ascommunication-process procedures are written.
 6. The contactless-IC-cardcommunication system according to claim 3, wherein the controller moduleunit provides an application firewall function for preventing thesoftware modules from interfering with each other and a secure executionenvironment for preventing the software modules from improperlyaccessing resources of the controller module.
 7. The contactless-IC-cardcommunication system according to claim 3, further comprising a downloadprocessing unit for downloading the software modules from an externalserver to the controller module unit.
 8. The contactless-IC-cardcommunication system according to claim 3, wherein the controller moduleunit is delegated by multiple through reader units so as to perform aprocess for the card-dependent command.
 9. A contactless-IC-cardcommunication method that is compatible with multiplecontactless-IC-card specifications including command classes differentfrom each other, the communication method comprising: a step ofencapsulating a card-dependent command received from a contactless ICcard into a through command and performing a card-independent processthat is independent of a difference between the individual contactlessIC card specifications; and a step of retrieving a card-dependentcommand from a through command and performing a card-dependent processin accordance with a corresponding contactless-IC-card specification.10. The contactless-IC-card communication method according to claim 9,further comprising: a step of generating a card-dependent command inaccordance with a corresponding contactless IC card and encapsulatingthe card-dependent command into a through command; and a step ofretrieving a card-dependent command from a through command andtransmitting a resulting command to the contactless IC card.
 11. Thecontactless-IC-card communication method according to claim 9, furthercomprising a step of executing a card determination procedure that iscommon to contactless-IC-card interface standards including carddetection, collision avoidance, and card determination.
 12. Thecontactless-IC-card communication method according to claim 9, wherein,in the step of performing the card-dependent process, multiple softwaremodules containing command classes corresponding to the respectivecontactless-IC-card specifications are selectively executed, acard-dependent command from the contactless IC card is processed, and acard-dependent command for the contactless IC card is generated.
 13. Thecontactless-IC-card communication method according to claim 9, whereinthe step of performing the card-dependent process comprises executing acommon process that is independent of a difference between thecontactless-IC-card specifications.
 14. The contactless-IC-cardcommunication method according to claim 12, wherein the software modulesare modularized for the respective contactless-IC-card specifications,in units of programs in which command groups and security algorithmscorresponding to the respective contactless-IC-card specifications aswell as communication-process procedures are written.
 15. Thecontactless-IC-card communication method according to claim 12, wherein,in the step of performing the card-dependent process, access toresources is limited so that secure execution of the software modules isexecuted without mutual interference of the software modules.
 16. Thecontactless-IC-card communication method according to claim 12, furthercomprising a step of downloading the software modules from an externalserver.